An administrator will typically assign roles or capabilities to users and groups of users, depending on their roles and responsibilities within an organization. For example, an end user may be able to access documents and data related to themselves, and edit their own settings. A group administrator may have further capabilities such as the ability to view and change users' settings, but not read their documents. A company level admin may have those capabilities across multiple groups and applications. In special situations such as discovery, special temporary roles may need to be created to provide specific access for a period of time to certain people. Selective control of access to particular features within a system by particular users is called “authorization,” which is separate from but related to the process of verifying the identity of credentialed users (“authentication”).
The administrator will prefer to manage these things from a single central point for all applications, rather than separately for each application. Therefore, all the above needs to apply across multiple applications and services, and across locations such as different clients sites. It also needs to apply between different service form factors: cloud services, on-premises solutions, and hybrids.
There is therefore a need for a shared granular authorization service that can be used with multiple applications, locations, and service form factors.
A naive solution to this problem would involve a centralized authorization service which responds to authorization requests from multiple applications and sites. However, if this is used for granular authorization, it introduces many round trips to the shared authorization service, resulting in unacceptable latency and delays.